Database size is a showing problem as databases are required to store an increasing amount of data. One cause of such size increase is that may relations in a database store identical or nearly identical data, each relation having a different purpose or retrieval format. A prior art method to reduce this redundancy is to use "views" or combinations of existing relations to obtain a new relation.
For purposes of describing this invention, a "relation" is a template for data storage, that is, the way the data is laid out. A "tuple" is an instance of a relation. In graphical terms, a "relation" is a table and a "tuple" is a row of a table.
A view is a new way to look at or "view" existing data. For example, there may be two relations in a database: one that contains employee name, address, and zip code (Table 1), and a second that contains zip code, city and state (Table 2).
TABLE 1 ______________________________________ ##STR1## ______________________________________
TABLE 2 ______________________________________ ##STR2## ______________________________________
A "view" is derived from these two relations to obtain the complete mailing address of each employee, i.e., the zip code in the first relation is a foreign key to the second relation to get the city and state. The results are shown in Table 3.
TABLE 3 ______________________________________ ##STR3## ______________________________________
This third relation does not exist in reality in the storage area of the database; it is a virtual relation and is defined only for retrieval of the information. Thus, a new relation may be obtained by using preexisting relations, without having to store the data for the new relation in the database. This method potentially saves large amounts of data storage that would otherwise be needed for the third relation.
For reading operations on the database, this recombining of preexisting data is completely transparent to users of the data base. Users do not know that the third relation is virtual; it appears to be just another relation. Furthermore, either physical relation (Table 1 and Table 2) can be read independently for its original purpose. For other operations on the database, however, the recombining of preexisting data is a problem.
For example, arbitrary operations that require a change in the virtual relation (i.e., insert, delete, or alter), cannot be accomplished directly, because modification of the view relation changes the underlying physical relations that form the view relation. Continuing with the example of the employee mailing address (Table 3) above, if the employee left the company, and the data in the view were deleted, this could mean that a tuple from both of the underlying relations would be deleted if the mailing address view is deleted from the database. In this case, the city, state and zip code of Table 2 would be deleted, because, as stated above, the user does not know that the Table 3 relation is virtual. Thereafter, any other virtual relation that referred to the zip code, city and state tuple from Table 2 that was deleted would no longer have valid data.
Obviously, additional mechanisms need to be added to the database to prevent this from happening. As these additional mechanisms are added, the number of anomalous situations increase. A. Furtado and M. Casanova, "Updating Relational Views" from Query Processing in Database Systems, Springer-Verlog, New York, 1983 describe many other anomalies, and the choices that must be made to deal with them. Solutions to these problems increase the complexity of database management while decreasing the memory savings of view relations.
Therefore, a problem in the art is that there is no database storage method that provides for view relations without increases of anomalies in the database.